2026 年，Vibe Coding 已經成為很多人開始寫程式的新方式。

簡單來說，就是不用自己從頭打一大堆程式碼，而是用「說話」的方式告訴 AI：

「我想做一個按鈕，按下去之後可以開始遊戲。」

幾秒鐘後，AI 可能就把需要的程式碼寫好了。
它甚至可以幫你寫完整功能、自動建立檔案、執行指令，甚至把一個小型專案架起來。
聽起來很厲害，但問題也跟著來了：

「如果 AI 把程式都寫完了，那工程師還需要做什麼？」
「這樣是不是只剩下複製、貼上？」
「久了以後，我自己的基本功會不會反而變差？」

我覺得這些擔心不是沒有道理。
但我後來發現，真正值得思考的問題可能是：

AI 幫你做事情的時候，你自己有沒有跟著學？

所以這次，我想做一個實驗：

讓 AI 幫我加速做事，同時看看自己能不能在過程中學會更多。

這次，我會挑戰一件自己以前從沒做過的事：

挑戰在 30 天內，從完全沒碰過遊戲引擎，到真的用 Vibe Coding 做出一款可以玩的 2D 卡牌遊戲。

🚀 我的起點：其實我也是遊戲開發新手

雖然我以前寫過不少程式，但在開始這個專案以前，我從來沒有真正研究過遊戲引擎。
第一款練習作品，我選的是 Roguelike Deckbuilder 類型的遊戲。
這個名字聽起來很複雜，其實可以簡單理解成：

一邊冒險、一邊收集卡牌，讓自己的牌組越來越強，最後打敗魔王。

我選它的原因很簡單。
這種遊戲可以很簡單，也可以非常複雜。簡單的版本只需要幾張卡牌、幾個數值，就可以開始玩；之後再慢慢增加內容。

所以對我來說，它很適合拿來當遊戲開發的第一個實驗。

為什麼選 Godot？

遊戲引擎選的是 Godot 4。
這個決定不是 AI 說了算。
我第一次詢問 Gemini 時，除了問：

「我想做一個自己的 Roguelike 卡牌文字遊戲。」

也問了：

「如果完全沒有遊戲開發經驗，應該使用什麼遊戲引擎？」

Gemini 推薦了 Godot。
但我沒有直接相信它，而是回頭查資料，確認這個推薦到底有沒有根據。
這也是我後面 30 天一直遵守的一個習慣：

AI 說的答案可以參考，但重要的事情還是要自己驗證。

一、AI 幫你舉起槓鈴，你的肌肉不會長大

想像一下，你去健身房。
你躺在臥推架上，準備把一根很重的槓鈴推起來。
結果怎麼推都推不起來。
這時候，旁邊來了一位超強的教練，伸手幫你托住槓鈴。

「來，推！」

於是你輕輕一推，槓鈴就上去了。
一組十下，漂亮完成。
但是有一個問題：

槓鈴確實被推上去了。

可是你的肌肉，真的因此變強了嗎？

這就是我認為 Vibe Coding 很容易遇到的一個陷阱。
AI 可以幫你寫程式、找錯誤、執行指令。
你看著程式成功執行，遊戲真的跑起來了，很容易產生一種錯覺：

「哇，我好像很會寫程式。」

但如果你完全不知道 AI 為什麼這樣做，那麼有一天遇到真正困難的問題，你可能還是會卡住。
因為：

「問題被解決」不等於「我學會了」。

明明身邊有這麼強大的工具，卻只拿到了結果，沒有把能力帶走。

二、先做，再學

Vibe Coding 其實也有一個很大的優點：

它可以讓你先做，再學。

如果今天要學一個完全陌生的遊戲引擎，傳統的方法可能是先學語法、變數、函式、API，再慢慢學遊戲引擎。

但問題是，東西真的很多。
而且在真正開始做遊戲之前，你很難知道哪些知識自己真的會用到。
所以我採用另一種方式，直接用 AI 進行 Vibe Coding：

先做出一個東西。
遇到問題，再去學解決這個問題需要的知識。

我實際使用的 Godot 4.7.1 裡，有超過一千種不同的類別，其中有兩百多種都跟 Node 有關。
但我的第一個遊戲畫面，其實只用了 7 種 Node：

• Label：顯示文字
• Button：按鈕
• Control：畫面的基本容器
• ColorRect：顯示一塊顏色
• HBoxContainer：讓東西橫著排
• VBoxContainer：讓東西直著排
• MarginContainer：幫內容留出邊界

光靠這 7 種東西，就可以做出第一個完整的遊戲畫面。

後來遊戲越做越漂亮，我才陸續遇到新的工具。
最後，整個遊戲實際使用到的 Node 類型，也只有 18 種左右。

所以一開始，我不需要知道一千多種 Node 是什麼。

遇到什麼，就學什麼。

學會之後，再拿這個新能力去解決下一個問題。

三、我的方法：攔截、追問、親手重做

所以，我最後給自己訂了一個很簡單的規則：

不要阻止 AI 幫你做事。
但不要讓 AI 幫你跳過學習。

我的方法只有三步：

1. 攔截 AI 的操作

當 AI 跳出：

「我想執行這個指令，可以嗎？」

先不要習慣性地按「允許」。

例如：

AI wants to run:
brew install --cask godot

不一定每一行都要研究。
但如果你看到一行後，會出現疑問？

「咦？這是什麼？」

那就值得停下來。
因為這可能就是一次學習的機會。

2. 追問

等 AI 做完事情，再回頭問它：

「剛才那行指令裡，--cask 是什麼意思？」
「這是什麼？」
「如果不加會怎樣？」

有空可以多追問：

「為什麼要這樣做？」

「如果不這樣做會怎樣？」

因為這類問題不只是在確認答案。
你還可以進一步了解：AI 為什麼會這樣做，以及不同做法可能帶來什麼差異。

3. 親手重做

最後，也是我覺得最重要的一步。
請 AI 給你一個最簡單的小例子。

然後：

自己打一遍。

自己執行一次，自己看它發生什麼事。
不需要把整個遊戲重寫一遍，只要把剛才真正沒搞懂的概念，自己做一次。

因為：「看懂」和「親手做過」，還是兩回事。

整個循環就是：

  AI 開始做事
      ↓
發現自己不懂它為什麼這樣做
      ↓
   先停下來
      ↓
   追問原因
      ↓
   親手做一次
      ↓
下一次遇到類似問題
      ↓
自己已經知道該怎麼判斷

這才是我真正想從 Vibe Coding 裡拿走的東西。
重點不在於 AI 幫我完成了多少，而是下一次遇到類似問題時，我能不能少依賴 AI 一點。

四、接下來的 30 天

所以，接下來這 30 天，對我來說不只是「叫 AI 幫我做一款遊戲」。
我也想實際試試看：

一個原本不懂遊戲引擎的人，能不能在 AI 的協助下，一邊做出遊戲，一邊學會 Godot 相關的遊戲開發知識。

我會從最基本的畫面開始，慢慢加入遊戲規則、卡牌、戰鬥、事件、平衡、美術，直到最後做出一個真正可以玩的版本。
過程中，我也會記錄：

• AI 幫我做了什麼
• 哪些東西是我自己學會的
• 哪些地方 AI 做錯了
• 我又是怎麼把問題找出來的

我想驗證的，其實是一個很簡單的問題：

AI 已經這麼會做了，我能不能在 Vibe Coding 的過程中，不只是把東西做出來，也真的從中學到東西？

這就是我接下來 30 天想做的實驗。

明天，開始真正動手。

本文同步發表於 Medium。